Computer systems are currently in wide use. Some computer systems are deployed as remote services that serve end users at end user computing systems. These end user computing systems may be referred to as end points.
In providing services to an end point, a remote computer system (e.g., a remote server environment), may manage connections to the end point. In doing so, the remote server environment may monitor traffic on end points and close (or kill) connections that have not been used in a certain amount of time. This can cause delays to users who are attempting to access the end point, through the connections.
By way of example, end users may use remote data centers or other remotely hosted computing systems. Engineers that maintain those remotely hosted computing systems may also attempt to access the environments at the end points in order to perform maintenance or other engineering operations. The engineering users may also query the end points for a whole host of different types of information that can be used in diagnosing problems, performing debugging operations, etc. In doing so, the engineers sometimes access the end points through a portal that maintains connections to the end points. It can take a relatively long time in order to establish this type of connection, and this can decrease the performance of the various computing systems involved, because they are using computing and memory overhead in order to establish the connections. It can also degrade the efficiency of the users involved, because they are spending time and other resources waiting for the connections to be established.
Some current systems attempt to maintain a cache of opened connections that can be used by the users to access the end points. However, the connections in the cache may have expired on the server side, because a given session has timed out for non-use. In that case, the connection needs to be reopened, before it can be used.
In these types of systems, it can be difficult to even know whether a cached connection is alive. Sometimes, one can only know that the connection has timed out when one attempts to use it. This can result in degraded performance. For instance, the user may submit a request to an instance of a runspace that runs the application process. The runspace may then attempt to submit the request to the application over the connection. That submission may fail because the connection has timed out. The runspace then attempts to reopen the connection and resubmit the user request in order to obtain results. In such a scenario, the user spends additional time because the runspace first submits the request and only then finds out that the connection has timed out. Only after finding that out, the runspace begins the process of reopening the connection. This is slower, in fact, than having the runspace simply open a new connection with each submission. However, even opening a connection can take an undesirable amount of time, and processing resources, and it can lead to unwanted inefficiencies.
The discussion above is merely provided for general background information and is not intended to be used as an aid in determining the scope of the claimed subject matter.